Embedded processors are widely used in a variety of applications and generally include processor circuitry that executes embedded code to perform desired functions. One type of embedded processor is a microcontroller which can be used, for example, to control the operation of a device or device component, such as a motor. Another type of embedded processor is a digital signal processor (DSP), which may be used, for example, in a variety of communications products, such as cellular phones. The use of an embedded processor to perform desired functions generally requires the development and debugging of a variety of concurrently executing applications with some applications taking advantage of embedded code. In many applications, the embedded code includes foreground code for performing time-critical (real-time) tasks, and background code for performing administrative or higher-level (non-real-time) tasks. Debugging of real-time code in any processor, either embedded or general purpose, has similar complications that may be addressed by concepts of the disclosed implementations. Similarly, application code may be embedded in a control system or provided by other conventional means. Conceptually, it is easier to consider embedded code in an embedded processor for the concepts of this disclosure; however, the disclosed issues and improvements are not limited to just this type of code and processor.
For certain applications, it may be particularly important to be able to debug the embedded code using real-time execution control. It may also be important to provide for real-time debug access to internal flags, registers and/or memory. The contents of such flags, registers, and memory provide the “context” of an embedded processor and the code it is executing at any given time. In normal operation, access to processor context is provided without using a debug monitor and without stopping the processor. Real-time execution control allows for the suspension of an embedded processor's execution of a given task while still allowing the processor to continue servicing other time-critical tasks. Thus, real-time execution control may allow the user of processor development and debug tools to interactively control the execution of code within the system without necessarily interfering with the processor's ability to perform time-critical tasks. For example, if embedded code is being debugged in a processor used to control a hard disk drive motor, the processor should not be allowed to stop the real-time threads/tasks that maintain the motor's functionality. Otherwise, the motor may go out of control and destroy the hard disk drive. Thus, it may be important to allow the processor to continue to execute the time-critical task of controlling the motor while the embedded instruction code is being debugged. In another example, debugging code within an active control system (e.g., cellular tower) should allow the cellular tower to maintain its core function (e.g., not drop all active calls) while allowing an application associated with a subset of connections to be analyzed (e.g., debugged).
On the other hand, if one or more real-time interrupts occur during a previously-initiated debug event, the processor context, for example, the operational state of the processor including the values of its internal memory and registers, may be subject to changes (e.g., from other functioning code). These types of changes affect the overall context and may provide spurious or misleading information to the debug host and ultimately the application developer performing the analysis. Accordingly, it may be desirable to take steps to ensure coherency of the debug context data. That is, the application developer should be able to trust the data retrieved is relative to where the debug breakpoint has been set, for example. The term “debug host” refers to a system external to but communicatively coupled to the processor(s) executing the code being executed in debug mode. For example, the debug host refers to a system that provides a user interface for an application developer performing the act of debugging. One example of a debug host is an in-circuit debugger (ICD). An ICD is a hardware device that connects to the microprocessor, for example via a JTAG or Nexus interface to allow the operation of the microprocessor to be controlled externally. JTAG is named after the Joint Test Action Group and is codified in an industry standard formally referred to as IEEE 1149.1. JTAG specifies the use of a dedicated debug port implementing a serial communications interface for low-overhead access without requiring direct external access to the system address and data buses. The interface may connect to an on-chip test access port (TAP) that implements a stateful protocol to access a set of test registers that present chip logic levels and device capabilities of various parts. Nexus is a standard formally referred to as IEEE-ISTO 5001-2003, incorporated by reference herein in its entirety. Nexus defines a standard set of connectors for connecting the debug tool to the target or system under test. Logically, data is transferred using a packet-based protocol. This protocol can be JTAG; or, for high-speed systems, an auxiliary port can be used that supports full duplex, higher bandwidth transfers.
When a user is debugging an application (or embedded system) request/response interactions, or packets may be transferred to a processor in a debug state (e.g., through the debug port). These interactions help control a debug session and may include: A) Run-time control representing that debug tools can start and stop the processor, modify registers, and single-step machine instructions. B) Memory access requests both while the processor is running and while it is paused. Access requests of a running processor may be required when debugging systems where it is not possible to completely halt the system under test. Examples include debugging an application in an active cell tower, where stopping digital feedback loops can cause undesired service interruptions. Note, disclosed Polite and Rude request types are introduced in this disclosure to further address memory access. C) Breakpoints representing that programs halt when a specified event (e.g., program counter has reached a breakpoint) has occurred. The event may sometimes be specified as a code execution address, or as a data access (read or write) to an address with a specified value. When debugging, several kinds of event tracing may be used. More details may be found in the above referenced standards which are incorporated by reference herein in their entirety.
Even though there are industry standards defining certain aspects of processor debugging capabilities and communication interfaces, external control (e.g., control from a debug host system) is typically restricted to the specific debugging capabilities “built-in” to the processor. Accordingly, more robust debug capabilities built-in to a processor may enhance the flexibility and usability for application developers to implement, test, and validate their code. This disclosure presents at least three examples of such improvements that may be used individually or collectively to assist application developers as described. More particularly, but not by way of limitation, this disclosure relates to processors having real-time execution control for debug functions to allow a) a real-time execution mode including interrupt handling to debug real-time applications, b) managing multiple real-time debug contexts, and c) maintaining a coherent debug view during multi-dimensional debugging operations. In the following Detailed Description section, each of these capabilities is independently summarized at a high level and then discussed in more detail with reference to the Figures as necessary.